Data transfer in cellular radio systems such as the Global System for Mobile Communications (GSM) or the Universal Mobile Telecommunications System (UMTS) is growing more and more complex with the advent of a mix of advanced multi-media applications and services. For optimum use and fair distribution of the scarce radio resource, more sophisticated data flow control techniques are required, where “flow control” is understood as the management of data flow between nodes of the cellular radio system, e.g. the mobile and base stations, so that the data can be handled at an efficient pace. Too much data arriving before a device at one of said nodes can handle it causes data overflow, meaning the data is either lost or must be retransmitted. An example for sophisticated data flow control techniques is the introduction of priority-based data flow control, where data is assigned a Quality of Service (QoS) parameter and/or a pre-defined service class and where data flow then is handled under consideration of the QoS parameter and/or service class, e.g. in order to optimise transfer of the data with the highest QoS requirements. Lack of proper priority-based data flow control can result in resources being wasted for lower priority services, ultimately dissatisfying the mobile subscriber.
FIG. 1 depicts a part of the protocol stack of the General Packet Radio Service (GPRS) that has been integrated into the GSM protocol stack in the scope of the GSM phase 2+ development in order to use the GSM radio resources more efficiently. The GPRS protocol stack controls the communication of a Mobile Station (MS) 1 and a Serving GPRS Support Node (SGSN) 2 via a Base Station Subsystem (BSS) 3.
In the sequel, the Logical Link Control (LLC) layer 4 of the GPRS protocol stack as depicted in FIG. 1 will be of primary interest. This layer and its functionality is standardised by the European Telecommunications Standardisation Institute (ETSI) and described in technical document 3GPP TS 04.64 (version 8.7.0, December 2001).
The LLC layer 4 is considered as a sub-layer of layer-2 in the ISO/OSI 7-layer reference model and operates above the Radio Link Control (RLC) layer 5 and Base Station Subsystem GPRS Protocol (BSSGP) layer 6 to provide logical links between layer-3 entities in a MS 1 and layer-3 peer entities in its associated SGSN 2. Above the LLC layer 4, i.e. in the network layer (layer-3 of the ISO/OSI model) 7, are located the Tunnelling of Messages (TOM) protocol 7-1, the GPRS Mobility Management (GMM) protocol 7-2, the Sub-Network Dependent Convergence (SNDC) layer 7-3, and the SMS protocol 7-4.
The RLC protocol 5 in combination with the Medium Access Control (MAC) protocol 8 operates on top of the GSM Radio Frequency (RF) channel (physical layer) 9 and realises the reliable packet-oriented transmission between MS 1 and BSS 3 by statistical multiplexing of several logical connections on the Packet Data Channels (PDCHs) available for GPRS in a radio cell. While RLC/MAC contains already an Automatic Repeat Request (ARQ) scheme to handle transmission errors on the air interface, the LLC protocol 4 provides a reliable ciphered logical link between MS 1 and SGSN 2 by applying flow control and error handling mechanisms known from link layer protocols like the Integrated Services Digital Network (ISDN). The ARQ scheme in LLC is not designed to handle transmission errors on the air interface, but for handling frame losses and errors in the fixed network or for link recovery after a cell change. The BSSGP 6, which is operating on top of a network service 10 such as Frame Relay (FR) and an underlying layer-1 (L1) protocol 11, is responsible for flow control between BSS 3 and SGSN 2. The conversion between the RLC protocol 5 and the BSSGP protocol 6 is performed by means of a relay 12 in the BSS 3.
The TOM protocol 7-1 is a generic protocol layer used for the exchange of TOM protocol envelopes between the MS 1 and the SGSN 2. The GMM protocol 7-2 uses the services of the LLC layer 4 to transfer messages between the MS 1 and the SGSN 2. It includes functions such as attachment and authentication, and transport of session management messages for functions such as PDP context activation and deactivation. Network layer protocols are intended to be capable of operating services derived from a wide variety of sub-networks and data links. GPRS supports several network layer protocols providing protocol transparency for the users of the service. Therefore, all functions related to transfer of network layer PDUs are carried out in a transparent way by the GPRS network entities. SNDCP 7-3 provides this adaptation of different network layers to the logical link by mapping different packet data protocols (e.g., Internet Protocol (IP) data packets) onto the services provided by the LLC layer.
The SMS protocol 7-4 uses the services of the LLC layer 4 to transfer short messages between the MS 1 and SGSN 2.
FIG. 2 gives a more detailed view of the structure of the LLC layer 4 as seen from the MS 1 side, wherein the signalling transfer between the components of FIG. 2 is given in dashed lines and the joint signalling and data transfer is given in solid lines. The LLC layer 4 comprises a plurality of LLC Entities (LLEs) 40-1 . . . 40-8, an LLC management entity 41, a multiplexer 42, and a plurality of LLC-SAPs 43-1 . . . 43-9. Via the SAPs 43-1 . . . 43-8, the services of the LLEs 40-1 . . . 40-8 are provided for the protocols of the network layer 7, i.e. the SMS protocol 7-1, the GMM protocol 7-2, the SNDCP 7-3 and the TOM protocol 7-4. There exists also a pure signalling link between the GMM protocol 7-2 and the LLC management entity 41 via the SAP 43-9. Below the LLC layer 4, the RLC layer 5 and the MAC layer 8 are situated. The LLC frames from the multiplexer 42 are passed to the RLC layer 5 via one single RLC-SAP 50-1.
The LLC layer 4 provides four LLC-SAPs 43-2 . . . 43-5 to the SNDCP 7-3, where the SNDCP 7-3 manages the actual data packet transmission. In GPRS, four radio priority levels are defined. Correspondingly, four LLC-SAPs are required for packet data transmission, wherein the SAP Identifier (SAPI) identifies the point at which LLC services are provided by an LLC entity to a network layer entity. The SAPIs for said four radio priority levels are SAPI=3, 5, 9 and 11, respectively. The services that are made available via the LLC-SAPs 43-2 . . . 43-5 are provided by the LLEs 40-2 . . . 40-5. Each LLE controls the information flow of N-PDUs that are transferred as LLC Service Data Units (LLC-SDUs) within LLC-PDUs on the LLC link/connection between peer LLEs in the MS 1 and SGSN 2, respectively. These N-PDUs are transferred between the LLE and the above SNDCP 7-3 via a corresponding LLC-SAP. LLEs provide the SNDCP 7-3 unacknowledged/acknowledged information transfer, flow control (in Asynchronous Balanced Mode) and frame error detection. Each LLC connection is identified by a Data Link Connection Identifier (DLCI) that consists of a SAPI and a Temporary Logical Link Identifier (TLLI). As already stated. The SAPI is used to identify the SAP on the SGSN 2 side and the MS 1 side of the LLC interface, SAPI is carried in the address field of each LLC frame. The TLLI is used to identify a specific MS 1. TLLI assignments is controlled by GMM. TLLI is not carried in LLC frames.
The multiplexer 42 represents an entity that multiplexes the LLC connections of the respective LLEs 40-1 . . . 40-8 and outputs LLC frames (LLC-PDUs) that are transferred to the peer multiplexer entity in the remote SGSN 2 LLC layer 4. On LLC frame transmission, the multiplexer 42 generates and inserts the Frame Check Sequence (FCS), performs the frame ciphering function, and provides SAPI-based LLC layer contention resolution between the various LLEs 40-1 . . . 40-8 whose connections are multiplexed. On LLC frame reception, the multiplexer 42 performs the frame decipher function and checks the FCS. If the frame passes the FCS check, the multiplex procedure distributes the LLC frame to the appropriate LLE. For the ciphering function, a ciphering key is produced with the ciphering algorithm, for instance starting from an identification key and a non-predictable random number generated by an authentication centre. The FCS typically consists of a 24 bit cyclic redundancy check (CRC) code. The CRC-24 is used to detect bit errors in the frame header and information fields.
When being passed to the RLC layer 5 via the RLC-SAP 50-1, the LLC frames from the multiplexer 42 are segmented into RLC data blocks. At the RLC layer 5 and MAC layer 8, a selective ARQ between the MS 1 and the network provides retransmission of erroneous RLC data blocks. When a complete LLC frame is successfully transferred across the RLC layer, it is forwarded to the peer LLC entity in the SGSN 2.
By multiplexing the connections of the different LLEs 40-1 . . . 40-8 into LLC frames, the multiplexer 42 provides a common interface between the LLC layer 4 and the RLC layer 5 (via the single RLC-SAP 50-1) for all signalling and data transfers. However, the multiplexer also represents a bottleneck for smooth data flow of the different LLC connections that are controlled by the respective LLEs 40-1 . . . 40-8. This is due to the fact that the RLC layer, which has a good view of the radio resources that are available for the transmission of its RLC data blocks, has no possibility to separately control the data flows of the different LLC connections over the single RLC-SAP 50-1 due to the multiplexing procedure. It is thus not possible for the RLC layer 5 to adapt the flows of the different LLC connections with their different QoS requirements to the transmission state of the underlying radio resource, a fact that deteriorates the overall data flow of the LLC-PDUs over the LLC links and thus also the flow of the N-PDUs that are contained as LLC-SDUs in the LLC-PDUs.